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Abstract 


Authentication, Authorization, and Accounting (AAA) servers, such as 
RADIUS and DIAMETER, are in use within the Internet today to provide 
authentication and authorization services for dial-up computers. 
Mobile IP for IPv4 requires strong authentication between the mobile 
node and its home agent. When the mobile node shares an AAA Security 
Association with its home AAA server, however, it is possible to use 
that AAA Security Association to create derived Mobility Security 
Associations between the mobile node and its home agent, and again 
between the mobile node and the foreign agent currently offering 
connectivity to the mobile node. This document specifies extensions 
to Mobile IP registration messages that can be used to create 
Mobility Security Associations between the mobile node and its home 
agent, and/or between the mobile node and a foreign agent. 
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1. Introduction 


AAA 
the 


services for 
valuable for 


servers, such as RADIUS 


dial-up computers. 


[11] and DIAMETER [12], are in use within 
Internet today to provide authentication and authorization 


Such services are likely to be 
mobile nodes using Mobile IP for IPv4 [1], when the 


nodes are attempting to connect to foreign domains with AAA servers. 


In this document Mobile IP for IPv4 is called 


"Mobile IPv4" or just 


"Mobile IP" for short, since no confusion with other versions is 


expected. 
outlined in RFC 2977 [13]; 


are 


Requirements for interactions between AAA and Mobile IP 
that document describes an 


infrastructure which enables AAA servers to authenticate and 
authorize network access requests from mobile nodes. See also 


appendix A. 


request for network access. 
functionality of the Mobile IP mobility agents so that they can 
translate between Mobile IP registration messages and the messages 
used within the AAA infrastructure, as described 
Mobility agents and AAA servers that conform to the requirements of 
RFC 2977 can be considered as appropriate network entities to support 


the message types specified in this document. 


2977 


Perkins 


It is then possible 


[13] for further details. 
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The Mobile IP Registration Request is considered to be a 


to augment the 


in RFC 2977. 


Please consult RFC 
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This specification makes use of a single AAA Security Association to 
create derivative Mobility Security Associations. A Mobility 
Security Association in this specification is a simplex connection 
that serves to authenticate MIPv4 control traffic between a MN and HA 
and/or a MN and FA. A Mobility Security Association is identified by 
the two end points, such as a MN IP address and a HA IP address, and 
a SPI. Two nodes may have one or more Mobility Security Associations 
established between each other; however, typically there is no reason 
to have more than one Mobility Security Association between two 
nodes. 


This document specifies extensions to Mobile IP registration messages 
that can be used to create Mobility Security Associations between the 
MN and FA and/or MN and HA based on the AAA Security Association 
between the MN and AAA server. These new Mobility Security 
Associations may then be used to calculate the Authentication Data 
needed by authentication extensions used in Mobile IP control 
messages. 


It is assumed that the security association between the mobile node 
and its AAA server has been appropriately configured so that the AAA 
server can provide key material to be used as the basis for the 
necessary Mobility Security Association(s) between the mobile node 
and its prospective mobility agents. 


AAA servers typically use the Network Access Identifier (NAI) [2] to 
uniquely identify the mobile node; the mobile node’s home address is 
not always necessary to provide that function. Thus, it is possible 
for a mobile node to authenticate itself, and be authorized for 
connection to the foreign domain, without having any home address. 
However, for Mobile IP to work, the mobile node is required to have a 
home address and a Mobility Security Association [1] with its home 
agent. When the Mobile IP Registration Reply packet is authenticated 
by the MN-AAA Authentication Extension [3], the mobile node can 
verify that the key material contained in the extensions were 
produced by the AAA server, and thus may be reliably used to create 
Mobility Security Associations with the home agent and/or the foreign 
agent. 


It is also assumed that the AAA entities involved (i.e., the AAAH, 
AAAL, and the AAA interface features of the foreign agents and home 
agents) all have means outside of the scope of this document for 
exchanging keys. The extensions within this document are intended to 
work with any AAA protocol suite that allows for such key exchange, 
as long as it satisfies the requirements specified in RFC 2977 [13]. 
One such AAA protocol is defined within the Diameter framework [14]. 
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2 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [4]. 


AAA Authentication, Authorization, and Accounting (see 
[10]). 
AAA entity A network node processing AAA messages according to the 


requirements for AAA protocols (see [10]). 


AAA Security Association 
A security association between a AAA entity and another 
node needing the services of that AAA entity. In this 
document all AAA Security Associations are between a 
mobile node and its home AAA server (AAAH). A mobile 
node’s AAA Security Association with its home AAA 
server (AAAH) may be based either on the mobile node’s 
IP address or on its NAI [2]. The key is referred to 
as “AAA-key" in this specification. 


Key A number, kept secret. Only nodes in possession of the 
key have any hope of using the security transform to 
obtain correct results. 


Key Generation Nonce 
Nonce data used for the purpose of creating a key. 


Mobility Security Association 
A Mobility Security Association is a simplex connection 
that applies security services to RFC 3344 MIPv4 
control traffic between a MN and HA (or MN and FA) 
using RFC 3344 Authentication Extensions. A Mobility 
Security Association is uniquely identified by the peer 
source and destination IP addresses and an SPI. Two 
nodes may have one or more Mobility Security 
Associations; however, typically there is no reason to 
have more than one Mobility Security Association 
between two nodes, except as a transient condition 
during re-keying events. 


Registration Key 
A key used in the MN-FA or MN-HA Mobility Security 
Association. A registration key is typically only used 
once or a very few times, and only for the purposes of 
verifying a small volume of Authentication data. 
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Security Algorithm 
A set of rules for using input data and a secret key 
for producing data for use in security protocols. 


SPI Security Parameters Index. The SPI is an arbitrary 
32-bit value that assists in the identification of an 


AAA, IP, or Mobility Security Association. 


Other terminology is used as defined in the base Mobile IP 


specification [1]. Furthermore, in order to simplify the discussion, 
we have used the word "Extension" instead of "Subtype of the 
Generalized Extension" in many cases. So, for instance, instead of 


using the phrase "The MN-FA Key Generation Nonce From AAA Subtype of 
the Generalized MN-FA Key Generation Nonce Reply Extension", we would 
instead use the phrase "The MN-FA Key Generation Nonce From AAA 
Extension". 


3. Overview of Operations with Key Generation Nonce Extensions 


When a mobile node depends on an AAA infrastructure to obtain 
authorization for network connectivity and Mobile IP registration, it 
may lack any pre-existing Mobility Security Associations with either 
its home agent, or the foreign agent controlling the access to the 
foreign network. The extensions defined in this document allow a AAA 
entity to supply key material to mobile nodes to be used as the basis 
of its Mobility Security Association with mobile agents. The AAA 
entity that will act on these extensions is part of the AAA 
infrastructure, and is typically identified within the foreign domain 
by methods outside the scope of this specification (see appendix A). 


The key material may be requested by the mobile node in new 
extensions (defined below) to Mobile IP Registration Request 
messages, and supplied to the mobile node in extensions to the Mobile 
IP Registration Reply messages. Alternatively, the AAA server MAY 
provide unsolicited key material via mobility agents to mobile nodes; 
the mobile node MUST then calculate new keys and update or create its 
relevant Mobility Security Association. The method by which key 
material is supplied to the mobility agents themselves is out of 
scope for this document, and would depend on the particular details 
of the security architecture for the AAA servers in the foreign and 
home domains (see RFC 2977 and appendix A). For the purposes of this 
document, we assume that there is a suitable AAA infrastructure 
available to the home and foreign agents, and that the mobile node 
does have an AAA Security Association with at least one AAA server in 
its home domain. 
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When a mobile node travels away from home, it may not have a Mobility 
Security Association with its home agent, perhaps because it does not 
yet have a home address [5]. The protocol and messages in this 
document are intended to facilitate the following operations which 
may occur between the mobile node, foreign agent, home agent, and AAA 
servers in the visited (local) domain (Authentication, Authorization 
and Accounting Local or AAAL) and in the home domain (Authentication, 
Authorization, and Accounting Home or AAAH). In the following 
sequence of messages, the only message flows specified in this 
document are the Registration Request between the mobile node and the 
foreign agent, and Registration Reply between the foreign agent and 
the mobile node. The other messages described here result from the 
presumed action of the AAA entities as described in RFC 2977. See 
also appendix B. 


1. If the mobile node does not have a Mobility Security Association 
with the foreign agent, it SHOULD include an MN-FA Key Generation 
Nonce Request extension (see Section 6.1) as part of its 
Registration Request that it sends to the Foreign Agent. 


2. If the mobile node does not have a Mobility Security Association 
with the home agent, it MUST add an MN-HA Key Generation Nonce 
Request extension (see Section 6.3) as part of its Registration 
Request that it sends to the Foreign Agent. 


3. If one or more AAA Key Generation Nonce Request extensions were 
added, the mobile node MUST add the MN-AAA Authentication 
extension to its Registration Request. 


4. By action of the foreign agent, which is presumed to be also a 
AAA entity, the mobile node’s key requests and authentication 
data are transferred to the local AAA server (AAAL), typically 
after reformatting to fit into the appropriate AAA messages, 
which are out of scope for this document. 


5. After the information within the MN-AAA Authentication extension 
is verified by the AAA server in the home domain (AAAH), it then 
also generates the key material that has been requested by the 
mobile node, for the necessary Mobility Security Associations. 


6. The respective keys for the Mobility Security Associations are 
distributed to the Home Agent and Foreign Agent via the AAA 
protocol. 

7. The mobile node receives the Registration Reply message from the 


Foreign Agent. 
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8. If a MN-HA Key Generation Nonce Request From AAA extension is 
present in the Registration Request message, then the mobile node 
MUST create or update its Mobility Security Association with the 
Home Agent indicated in the corresponding Registration Reply, 
using the key computed from the key material in the MN-HA Key 
Generation Nonce From AAA extension. In this case, if no MN-HA 
Key Generation Nonce Reply extension is present, the mobile node 
MUST discard the Registration Reply. 


9. Using its (perhaps newly created) Mobility Security Association 
with the home agent, the mobile node authenticates the 
Registration Reply message by checking the Authentication Data in 
the Mobile-Home Authentication extension. If the check fails, 
the MN MUST discard the Registration Reply and the new Mobility 
Security Association, reverting to the old Mobility Security 
Association with the home agent, if any. 


10. If the Registration Reply passes authentication and contains a 
MN-FA Key Generation Nonce From AAA extension (see section 6.2), 
the mobile node generates the registration key using the Key 
Generation Nonce provided, according to its AAA Security 
Association with the AAA. The resulting registration key is used 
to establish the mobile node’s Mobility Security Association with 
its foreign agent, and is used to compute the authentication data 
used in the Mobile-Foreign authentication extension. 


If verification of the Mobile-Foreign authentication extension 
fails, and if the MN-FA Key Generation Nonce Reply extension was 
not protected by another, valid authentication extension, the MN 
MUST discard the new Mobility Security Association, reverting to 
the old Mobility Security Association with the foreign agent, if 
any. 


Any registration reply containing the MN-HA Key Generation Nonce From 
AAA extension MUST also contain a subsequent Mobile Home 
Authentication extension, created using the generated MN-HA key. 
Similarly, a reply containing the MN-FA Key Generation Nonce From AAA 
extension MUST also contain a subsequent Mobile Foreign 
Authentication extension, created using the registration key. 


4. Mobility Security Associations 


Mobility Security Associations between Mobile IP entities (mobile 
nodes, home agents, foreign agents) contain both the necessary 
cryptographic key information and a way to identify the cryptographic 
transform that uses the key to produce the authentication information 
that is present in the Mobile-Home Authentication extension or the 
Mobile-Foreign Authentication extension. In order for the mobile 


Perkins & Calhoun Standards Track [Page 7] 


RFC 3957 AAA Keys for Mobile IPv4 March 2005 


node to make use of key material created by the AAA server, the 
mobile node also has to be able to identify and select the 
appropriate cryptographic transform that uses the key to produce the 
authentication. 


The transform identifiers are the same as those used in IPsec. They 
are tabulated in the list of Authentication Algorithms allowable as 
values for the "Attribute Type" (5) (i.e., "Authentication 
Algorithm"), one of the classifications in the tabulated Attribute 
Types for "IPsec Security Association Attributes". See 
http://www.iana.org/assignments/isakmp-registry for the full listing 
of all Attribute Types and other Attributes for IPsec Security 
Associations. 


Mobility Security Associations shared between mobile nodes and home 
agents also require a replay protection method. The following table 
contains the supported replay detection methods. 


Replay Method Name Reference 
0,1 Reserved 
2 Timestamps RFC 3344 [1] 
3 Nonces RFC 3344 [1] 
4-65535 Unallocated 

5. Key Generation Nonce Creation and Key Derivation 


This section contains the procedures followed in the creation of the 
Key Generation Nonce by AAA servers, and the key derivation 
procedures used by mobile nodes. Note that the AAA servers will also 
deliver the keys to the mobility agents (home agent, foreign agent) 
via the AAA protocol. AAA servers that follow these procedures will 
produce results that can be understood by mobile nodes. The mobility 
agents will faithfully transcribe the results into the appropriate 
Mobile IP extensions. 


The following example uses HMAC-SHA1 [6]. All mobile nodes and 
mobility agents implementing Mobile IP [1] and implementing the 
extensions specified in this document MUST implement HMAC-SHA1 [1]. 
Other message authentication codes or keyed hash functions MAY also 
be used. The particular algorithm used is configured as part of the 
AAA Security Association between the MN and the AAAH server, which is 
in turn indexed by the AAA SPI. 
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The following steps are performed on the AAAH server: 


1. The AAA server identifies the mobile node. If the NAI field is 
present in the Registration Request, then the NAI is used as the 
mobile node identifier. Otherwise, the Home Address field of the 
Registration Request is used. 


2. The AAA server generates a random [7] value of at least 128 bits 
to be used as the Key Generation Nonce. 


3. The AAA server inserts the random value into the Key Generation 
Nonce Reply extension in the "Key Generation Nonce" field. 


The following steps are performed by the mobile node (here | | 
represents concatenation): 


1. The mobile node calculates 


key = HMAC-SHA1 (AAA-key, {Key Generation Nonce | | mobile node 
identifier}) 


Here the Key Generation Nonce is from the extension in the 
Registration Reply, and the mobile node identifier is the MN’s 
NAI, if present in the Registration Request, or the Home Address 
from the Registration Request otherwise. 


2. The mobile node creates the Mobility Security Association(s), 
using the resulting key and the other relevant information in the 
Key Generation Nonce Extension. 


The secret key used within the HMAC-SHA1 computation is indicated by 
the AAA Security Association indexed by the AAA SPI, which has been 
previously configured as the basis for the AAA Security Association 
between the mobile node and the AAA server creating the key material. 


6. Key Generation Extensions 


This section defines new Extensions to Mobile IP Registration 
Requests and Replies [1]. 
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6.1. Generalized MN-FA Key Generation Nonce Request Extension 


Figure 1 illustrates the Generalized MN-FA Key Generation Nonce 
Request Extension (MN-FA KeyGen Request for short). 


0 1 2 3 
0123456789012345678°9012345678<9021 
—+-—+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4t-4t-4+-4t-t-4-4+-t-4t-4+-4t-4+-4+-4+-4t-4+-4+-4+-4 
Type | Subtype | Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Mobile Node SPI | 
—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
MN-FA Key Generation Nonce Request Subtype Data ... 
—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + —+— + 


Figure 1: The Generalized Mobile IP MN-FA Key Generation 
Nonce Request Extension 


Type 40 (not skippable) (see [1] and section 8) 


Subtype A number assigned to identify the way in which the 
MN-FA Key Generation Nonce Request Subtype Data is 
to be used when generating the registration key. 


Length The 16-bit Length field indicates the length of the 
extension. It is equal to the number of bytes in 
the MN-FA Key Generation Nonce Request Subtype Data 
plus 4 (for the Mobile Node SPI field). 


Mobile Node SPI The Security Parameters Index that the mobile node 
will assign for the Mobility Security Association 
created for use with the registration key. 


MN-FA Key Generation Nonce Request Subtype Data 
Data needed to carry out the creation of the 
registration key on behalf of the mobile node. 


The MN-FA KeyGen Request defines a set of extensions, identified by 
subtype, which may be used by a mobile node in a Mobile IP 
Registration Request message to request that some other entity create 
a Registration Key for use by the mobile node with the mobile node's 
new foreign agent. 
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This document defines the subtype 1 for the MN-FA Key Generation 
Nonce >From AAA Request (MN-FA AAA KeyGen Request for short). The 
MN-FA AAA KeyGen Request has a zero-length Subtype Data field and 
MUST appear in the Registration Request before the MN-AAA 
Authentication extension. 


6.2. Generalized MN-FA Key Generation Nonce Reply Extension 


The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA 
KeyGen Reply for short) supplies keying material requested by the 
MN-FA KeyGen Request extension. Figure 2 illustrates the format of 
the Generalized MN-FA Key Generation Nonce Reply Extension. 


0 1 2 3 

On DEZES 4.15: 65 7 89 OE 2 34 SO 8 DO 2 346 BOs Ord 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Subtype | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MN-FA Key Generation Nonce Reply Subtype Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 2: The Generalized Mobile IP MN-FA Key 
Generation Nonce Reply Extension 


Type 41 (not skippable) (see [1] and section 8) 


Subtype A number assigned to identify the way in which the MN-FA 
Key Generation Nonce Reply Subtype Data is to be used to 
obtain the registration key. 


Length The 16-bit Length field is equal to the number of bytes in 
the MN-FA Key Generation Nonce Reply Subtype Data. 


MN-FA Key Generation Nonce Reply Subtype Data 
An encoded copy of the keying material, along with any 
other information needed by the recipient to create the 
designated Mobility Security Association. 


For each subtype, the format of the MN-FA Key Generation Nonce Reply 
Subtype Data has to be separately defined according to the particular 
method required to set up the Mobility Security Association. 


For the subtype defined in this document, the MN-FA Key Generation 
Nonce supplied in the data for a subtype of this extension may come 
as a result of a request which was sent using a subtype of the 

Generalized MN-FA Key Generation Nonce Request Extension. In such 
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cases, the SPI to be used when employing the Mobility Security 
Association defined by the registration key is the same as given in 
the original request. 


Once the mobile node creates the Mobility Security Association with 
the foreign agent, by using the transform indexed by the AAA SPI, it 
stores that Mobility Security Association indexed by the FA SPI in 
its list of Mobile Security Associations. 


If the foreign agent receives a Registration Reply that has no MN-FA 
Key Generation Nonce Reply extension, and if it has no existing 
Mobility Security Association with the mobile node, the foreign agent 
MAY change the Code value of the Registration Reply to MISSING_MN_FA 
(see section 7), effectively causing the registration to fail. 


This document defines subtype 1 of the MN-FA KeyGen Reply for the 
MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply 
for short), shown in figure 3. 


0 1 2 3 
012345678901234567890123456789041 
SHA t rtm t rt tot rt t ata t nto ta tata tota TR E e A E 
Lifetime | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++HH 
AAA SPI | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
FA SPI | 
E n n n e E E e tata a E S a a A S S a a S a A A 
Algorithm Identifier | Key Generation Nonce ... 
C a A r a Aa e A a a E a a e a A T A a 


+— + — + — + — + 


Figure 3: The MN-FA Key Generation Nonce From AAA 
Subtype-Specific Data 


lifetime This field indicates the duration of time (in seconds) for 
which the keying material used to create the registration 
key is valid. 


AAA SPI A 32-bit opaque value, indicating the SPI that the mobile 
node must use to determine the transform to use for 
establishing the Mobility Security Association between the 
mobile node and its prospective foreign agent. 


FA SPI The SPI for the Mobility Security Association to the FA 
that the mobile node creates using the Key Generation 
Nonce. 
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Algorithm Identifier 
This field indicates the transform to be used (stored as 
part of the Mobility Security Association with the foreign 
agent, and selected from among the values in the 
"Authentication Algorithm" table cited in section 4), for 
future computations of the Mobile-Foreign Authentication 
Extension. 


Key Generation Nonce 
A random [7] value of at least 128 bits. 


The MN-FA AAA KeyGen Reply extension MUST appear in the Registration 
Reply before the Mobile-Foreign Authentication extension. 


The Key Generation Nonce is provided by the AAA server for use by the 
mobile node in creating the registration key, which is used to secure 
future Mobile IP registrations with the same foreign agent. 


6.3. Generalized MN-HA Key Generation Nonce Request Extension 


Figure 4 illustrates the Generalized MN-HA Key Generation Nonce 
Request Extension (MN-HA KeyGen Request for short). 


Type 42 (not skippable) (see [1] and section 8) 


Subtype a number assigned to identify the way in which the 
MN-HA Key Generation Nonce Request Subtype Data is 
to be used when generating the registration key. 


Length The 16-bit Length field indicates the length of the 
extension. It is equal to the number of bytes in 
the MN-HA Key Generation Nonce Request. 


0 1 2 3 

(0a EEES E E S 879-0. S ES E E A E e E OL. 2.34 546 27 849-10 

—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type | Subtype | Length 

—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Mobile Node SPI | 

—-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

MN-HA Key Generation Nonce Request Subtype Data 
—+—+-4+-4+-4+-4+-4+-—4+-—4+-4+-4+-4+-4+-4t-4+-4+-4-4t-4+-4+-t-4t-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+ 


+—+—4+—+ 


Figure 4: The Generalized Mobile IP MN-HA Key Generation 
Nonce Request Extension 


Subtype Data plus 4 (for the Mobile Node SPI field). 
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Mobile Node SPI The Security Parameters Index that the mobile node 
will assign for the Mobility Security Association 
created for use with the registration key. 


MN-HA Key Generation Nonce Request Subtype Data 
Data needed to carry out the creation of the MN-HA 
key on behalf of the mobile node. 


The MN-HA KeyGen Request Extension defines a set of extensions, 
identified by subtype, which may be used by a mobile node in a Mobile 
IP Registration Request message to request that some other entity 
create an MN-HA key for use by the mobile node with the mobile node’s 
new home agent. 


This document defines the subtype 1 for the MN-HA Key Generation 
Nonce from AAA Request (MN-HA AAA KeyGen Request for short). The 
MN-HA AAA KeyGen Request has a zero-length Subtype Data field and 
MUST appear in the Registration Request before the MN-AAA 
Authentication extension. 


6.4. Generalized MN-HA Key Generation Nonce Reply Extension 


The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA 
KeyGen Reply for short) supplies keying material requested by the 
MN-HA KeyGen Request extension. Figure 5 illustrates the format of 
the Generalized MN-HA Key Generation Nonce Reply Extension. 


0 1 2 3 
0123456789012345678°9012345678<9021 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Subtype | Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Lifetime | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
MN-HA Key Generation Nonce Reply Subtype Data 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + — +— + 


Figure 5: The Generalized Mobile IP MN-HA Key 
Generation Nonce Reply Extension 


Type 43 (not skippable) (see [1] and section 8) 
Subtype a number assigned to identify the way in which the MN-HA 


Key Generation Nonce Reply Subtype Data is to be used to 
obtain the MN-HA key. 
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Length The 16-bit Length field indicates the length of the 
extension. It is equal to the number of bytes in the MN- 
HA Key Generation Nonce Reply Subtype Data plus 4 (for the 
Lifetime field). 


Lifetime This field indicates the duration of time (in seconds) for 
which the MN-HA key is valid. 


MN-HA Key Generation Nonce Reply Subtype Data 
Data used to derive the MN-HA key, along with any other 
information needed by the mobile node to create the 
designated Mobility Security Association with the home 
agent. 


For each subtype, the format of the MN-HA Key Generation Nonce Reply 
Subtype Data has to be separately defined according to the particular 
method required to set up the Mobility Security Association. 


This document defines subtype 1 of the MN-HA KeyGen Reply for the 
MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply 
for short), shown in figure 6. 


0 1 2 3 
01234567890123456789012345678<901 
—tit-t-4-t-4-t-4-t-t-ti toto toto t-tit-tititatitititititatitatitat 
AAA SPI | 
—tit-t-t-t-t-t-t-t-t-tit-tit-ti tata t-ti tata tititi titi tatitititat 
HA SPI | 
—tit-t-+-t-4-t-4-t-4-t-4-ti toto tata E S S 
Algorithm Identifier | Replay Method 
—titat-t-t-t-t-t-t-t-titati tata tati titi tatititatitititititatitat 
Key Generation Nonce 
—tito-t-t-t-t-t-t-titoti toto ta tito O titi tititititatitatitat 


+—+—4+—4+—+4+ 


Figure 6: The MN-HA Key Generation Nonce From AAA 
Subtype-Specific Data 


AAA SPI A 32-bit opaque value, indicating the SPI that the mobile 
node must use to determine the transform to use for 
establishing the Mobility Security Association between the 
mobile node and its home agent. 


HA SPI The SPI for the Mobility Security Association to the HA 
that the mobile node creates using the Key Generation 
Nonce. 
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Algorithm Identifier 
This field indicates the transform to be used for future 
computations of the Mobile-Home Authentication Extension 
(see section 4). 


Replay Method 
This field contains the replay method to be used for 
future Registration messages (see section 4). 


Key Generation Nonce 
A random [7] value of at least 128 bits. 


The MN-HA AAA KeyGen Reply subtype-specific data is shown in figure 
6. The Mobile Node calculates the MN-HA key using the Key Generation 
Nonce provided by the AAA server. The calculation proceeds by using 
the key shared between the mobile node and the AAA server that has 
previously been configured for securing all such communication 
requirements with the AAA server which will be contacted within the 
AAA infrastructure (see appendix A). The MN-HA key is intended for 
use by the mobile node to secure future Mobile IP registrations with 
its home agent. The MN-HA AAA KeyGen Reply extension MUST appear in 
the Registration Reply before the MN-HA Authentication extension. 


Once the mobile node creates the MN-HA Key, by using the transform 
specified in the AAA SPI, it stores the HA Security Information 
indexed by the HA SPI in its list of Mobile Security Associations. 
The mobile node uses the Identification field data from the 
Registration Reply as its initial synchronization data with the home 
agent. 


7. Error Values 
Each entry in the following table contains the name of the Code [1] 


value to be returned in a Registration Reply, the value for that 
Code, and the section in which the error is first mentioned in this 


specification. 
Error Name Value Section 
MISSING_MN_ FA 107 6.2 


8. IANA Considerations 


This document defines 4 new extensions (see Section 6) taken from the 
(non-skippable) numbering space defined for Mobile IP registration 
extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The 
values for these extensions are: 
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Name Value Section 
MN-FA-KeyGen Request 40 O51 
MN-FA-KeyGen Reply 41 6.2 
MN-HA-KeyGen Request 42 6.3 
MN-HA-KeyGen Reply 43 6.4 


IANA has created and will maintain a new registry for the KeyGen 
Request/Reply subtypes. The initial contents of the registry is a 
single entry for the subtypes defined in this document: 


Name Value Section 


KeyGen Request/Reply from AAA ii 6 


New subtypes for these two registries are assigned through Standards 
Action as defined in [9]. 


IANA has assigned a code value for error MISSING_MN_FA, listed in 


section 7. This value has been taken from the space of error values 
conventionally associated with rejection by the foreign agent (i.e., 
64-127). 


IANA has created and will maintain a namespace for the Replay Method 
Identifier. This specification makes use of 2 and 3; all other 
values other than zero (0) and (1) are available for assignment, 
pending review and approval by a Designated Expert [9]. 


9. Security Considerations 


The extensions in this document are intended to provide the 
appropriate level of security for Mobile IP entities (mobile node, 
foreign agent, and home agent) to calculate the Authentication Data 
needed by authentication extensions used with Mobile IP registration 
messages. The Mobility Security Associations resulting from use of 
these extensions do not offer any higher level of security than what 
is already implicit in use of the AAA Security Association between 
the mobile node and the AAAH. In order to deny any adversary the 
luxury of unbounded time to analyze and break the secrecy of the AAA 
Security Association between the mobile node and the AAA server, that 
AAA Security Association MUST be refreshed periodically. 


The provisioning and refreshing of the AAA key in the MN and AAA 
server is outside the scope of this document. 


Since the Reply extensions defined in this specification only carry 


Key Generation Nonces, which are used to derive keys, they do not 
expose any data that could be used in an attack aimed at recovering 
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the key shared between the mobile node and the AAA. The authors do 
not believe this specification introduces any new security 
vulnerability. 
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Appendix A. AAA Infrastructure 


In this appendix, we attempt to capture the main features of a basic 
model for operation of AAA servers that is assumed for understanding 
of the use of the Mobile IP registration extensions described in this 
document. This information has been adapted from the discussion in 
RFC 2977 [13]. 


Within the Internet, a mobile node belonging to one administrative 
domain (called the home domain) often needs to use resources provided 
by another administrative domain (called the foreign domain). A 
foreign agent that handles the mobile node’s Registration Request is 
likely to require that the mobile node provide some credentials that 
can be authenticated before access to the resources is permitted. 
These credentials may be provided as part of the Mobile-AAA 
Authentication extension [3], relying on the existence of an AAA 
infrastructure such as is described in this section, and also 
described in RFC 2977 and RFC 3012 [3]. Such credentials are 
typically managed by entities within the mobile node’s home domain. 
They may be also used for setting up secure communications with the 
mobile node and the foreign agent, or between the mobile node and its 
home agent if necessary. 


Local Domain Home Domain 
+-------------- + +---------------------- + 
| +=- | | tonsa | 
ls 7 | | | | | 
| AAAL | | | | AAAH 

+------------------- + 
| +---+--+ | | +-----—- + | 
| | | | | 
| | | Sa rare cen + 
4------ + | ee | 
MN = mobile node 
MN = Je = FA | FA = foreign agent 
| | | | | | AAAL = local authority 
+-----—- + | +-----—- + | AAAH = home authority 
EE : 


Figure 7: AAA Servers in Home and Local Domains 


The foreign agent often does not have direct access to the data 
needed to verify the credentials. Instead, the foreign agent is 
expected to consult an authority (typically in the same foreign 
domain) in order to request proof that the mobile node has acceptable 
credentials. Since the foreign agent and the local authority (AAAL) 
are part of the same administrative domain, they are expected to have 
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established, or be able to establish for the necessary lifetime, a 
secure channel for the purposes of exchanging sensitive (access) 
information, and keeping it private from (at least) the visiting 
mobile node. 


The local authority (AAAL) itself may not have enough information 
stored locally to carry out the verification for the credentials of 
the mobile node. In contrast to the foreign agent, however, the AAAL 
is expected to be configured with enough information to negotiate the 
verification of mobile node credentials with its home domain. The 
home and foreign domains should be configured with sufficient IP 
Security Associations (i.e., IPsec) and access controls so that they 
can negotiate the authorization, and also enable the mobile node to 
acquire Mobility Security Associations with the mobility agents 
within the foreign domain. For the purposes of the key exchanges 
specified within this document, the authorization is expected to 
depend only upon secure authentication of the mobile node’s 
credentials. 


Once the authorization has been obtained by the local authority, and 
the authority has notified the foreign agent about the successful 
negotiation, the foreign agent can deliver the Registration Reply to 
the mobile node along with the key material. 


In figure 7, there might be many mobile nodes from many different 
Home Domains. Each Home Domain provides a AAAH that can check 
credentials originating from mobile nodes administered by that Home 
Domain. There is a security model implicit in figure 7, and it is 
crucial to identify the specific security associations assumed in the 


security model. These IP Security Associations are illustrated in 
figure 8, and are considered to be relatively long-lived security 
associations. 


First, it is natural to assume that the mobile node has an AAA 
Security Association with the AAAH, since that is roughly what it 
means for the mobile node to belong to the home domain. 


Second, from the model illustrated in figure 7 it is clear that AAAL 
and AAAH have to share an IP Security Association, because otherwise 
they could not rely on the authentication results, authorizations, 
nor even the accounting data which might be transacted between them. 
Requiring such bilateral IP Security Associations is, however, in the 
end not scalable; the AAA framework must provide for more scalable 
mechanisms, but the methods by which such a broker model is to be 
created are out of scope for this document. See RFC 2977 for more 
details. 
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Finally, from figure 7, it is clear that the foreign agent can 
naturally share an IP Security Association with the AAAL. This is 
necessary in order for the model to work because the foreign agent 
has to have a way to find out that it is permissible to allocate the 
local resources to the mobile node, and further to transmit any 
successful Registration Reply to the mobile node. 


Figure 8 illustrates the IP Security Associations we understand from 
our proposed model. Note that there may be, by mutual agreement 
between AAAL and AAAH, a third party inserted between AAAL and AAAH 
to help them arbitrate secure transactions in a more scalable 
fashion. The broker model which has been designed to enable such 
third-party processing should not have any effect on the Mobile IP 
extensions specified in this document, and so no description is 
provided here; see RFC 2977 [13] for more details. 


+------ + +-—---- + 
| | | | 
| AAAL +-------------- + AAAH | 
| | | | 
+-—-+--+ +--—+-—-+ 
+---+--+ +-—+---+ 

MN = mobile node | | | 

FA = foreign agent | FA | | MN | 

AAAL = local authority | | | 

AAAH = home authority poan + +----- + 


Figure 8: IP Security Associations 


Nodes in two separate administrative domains (for instance, AAAH and 
AAAL) often must take additional steps to verify the identity of 
their communication partners, or alternatively to guarantee the 
privacy of the data making up the communication. While these 
considerations lead to important security requirements, as mentioned 
above in the context of security between servers, we consider the 
exact choice of IP Security Associations between the AAA servers to 
be beyond the scope of this document. The choices are unlikely to 
depend upon Mobile IP, or any specific features of the general model 
illustrated in figure 7. On the other hand, the Mobility Security 
Associations needed between Mobile IP entities are of central 
importance in the design of the key derivation extensions in this 
document. 
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One further detail deserves mention. The Mobility Security 
Association to be established between the mobile node and the foreign 
agent has to be communicated to the foreign agent as well as to the 
mobile node. The following requirements are placed on the mechanism 
used by the AAA infrastructure to effect key distribution: 


- The AAAH must establish strong, fresh session keys. 

- The mechanism must maintain algorithm independence, allowing for 
the distribution of authentication algorithm identification along 
with the keys. 


- The mechanism must include replay detection. 


—- The mechanism must authenticate all parties, including the AAA 
servers and the FA and HA. 


-— The mechanism must provide for authorization of the client, FA, 
and HA. 


- The mechanism must not rely on plaintext passwords. 

- The mechanism must maintain confidentiality of session keys. 

-— The mechanism must uniquely name session keys. 

- The mechanism must be such that the compromise of a single FA and 
HA cannot compromise any other part of the system, including 
session keys and long-term keys 


- The mechanism must bind key(s) to an appropriate context 


—- The mechanism must not expose the keys to entities other than the 
AAAH and FA (or HA in the case of key distribution to the HA). 


The way that the key is distributed to the foreign agent (or home 
agent) is expected to be handled as part of the AAA protocol 
processing between the AAAH and AAAL, and the further AAA protocol 


processing between the AAAL and the foreign agent. Such processing 
is outside the scope of this document, but must satisfy the above 
requirements. 
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Appendix B. Message Flow for Requesting and Receiving Registration Keys 


In this section, we show message flows for requesting and receiving a 
registration key from the AAA infrastructure, described in section A. 
Challenge values, as specified in [3], might be added to the 
Advertisement and Registration messages for additional replay 
protection, but are not illustrated here. 


Diagram 9 illustrates the message flow for the case when the mobile 
node explicitly requests keying material to create registration keys. 


MN FA AAA Infrastructure 
| 
|<--- Advertisement----- | 

| (if needed) | 

—- RReq+AAA Key Req.--> 

| |--- RReq + AAA Key Req.--->| 

| | | 

| |<--- RRep + AAA Key Rep.---| 

|<-- RRep+AAA Key Rep.--| 

| | 


Figure 9: Message Flows for Requesting and 
Receiving Key Generation Nonce 


In diagram 9, the following message flow is illustrated: 


1. The foreign agent disseminates an Agent Advertisement. This 
advertisement MAY have been produced after receiving an Agent 
Solicitation from the mobile node (not shown in the diagram). 


2. The mobile node creates a Registration Request including the MN-HA 
AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed, 
along with an authorization-enabling authentication extension as 
required by Mobile IP [1]. 


3. The foreign agent relays the Registration Request and/or Key 
Request (s) to its locally configured AAA Infrastructure (see 
appendix A), according to local policy. 


4. The foreign agent receives a AAA Response with the appropriate 
indications for authorizing connectivity for the mobile node. 
Along with this AAA Response, the foreign agent may also receive 
key material by some secure method appropriate for communications 
between it and its local AAA infrastructure. At this point if the 
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foreign agent has not relayed the Registration Request, it 
forwards it directly to the Home Agent and waits fora 
Registration Reply (not shown in the figure). 


5. The foreign agent relays the Registration Reply to the mobile 
node, along with the new AAA KeyGen Reply extensions to be used by 
the mobile node to establish Mobility Security Associations with 
the relevant mobility agents (foreign agent and/or home agent). 


Diagram 10 illustrates the message flow for the case when the mobile 
node receives unsolicited keying material from the AAA 
Infrastructure. 


MN FA AAA Infrastructure 


<--- Advertisement----- 
(if needed) 


<-- RReptAAA Key Rep.-- 


Figure 10: Message Flow for Receiving Unsolicited 
Key Generation Nonce 


In diagram 10, the following message flow is illustrated: 


1. The foreign agent disseminates an Agent Advertisement. This 
advertisement MAY have been produced after receiving an Agent 
Solicitation from the mobile node (not shown in the diagram). 


2. The mobile node creates a Registration Request including an 
authorization-enabling authentication extension as required by 
Mobile IP [1]. 


3. The foreign agent sends a AAA Request (possibly containing the 
Registration Request) to its locally configured AAA Infrastructure 
(see appendix A), according to local policy. 


4. The foreign agent receives a AAA Response with the appropriate 
indications for authorizing connectivity for the mobile node. 
Along with this AAA Response, the foreign agent may also receive 
key material by some secure method appropriate for communications 
between it and its local AAA infrastructure. At this point, if 
the foreign agent has not relayed the Registration Request, it 
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forwards it directly to the Home Agent and waits fora 
Registration Reply (not shown in the figure). 


5. The foreign agent relays the Registration Reply to the mobile 
node, along with the new KeyGen Reply extensions to be used by the 
mobile node to establish Mobility Security Associations with the 
relevant mobility agents (foreign agent and/or home agent). 
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